Nginx处理图片，就是这么简单
各位小伙伴，又有东西分享给大家了(又TM踩坑了！！！)
最近，由于业务需求，项目要根据不同的前端或者移动端环境，使用不同大小的图片资源，我当时就想，这TM和我有什么关系，我又不是切图的......
然而……，没有那么多然而，搞吧~~~
一通google、baidu之后，发现一个牛X的东西，nginx的image_filter，不得不说，nginx是真牛X
nginx官方文档：http://nginx.org/en/docs/http/ngx_http_image_filter_module.html
在官方的介绍中，该模块不是默认安装模块，需要在编译时通过添加参数'--with-http_image_filter_module'来开启，并且，该模块依赖libgd，所以，GD库你得装，安装这里就不多说了，网上文章漫天飞，提一嘴的是，nginx重新编译，到make就可以了，别手贱install，自己注意！！！
安装好该模块之后，就可以爽了，先来个动图感受一下(说明一下，我静态资源只存有原图)
只需要在服务端存储原图静态资源，通过请求的时候添加图片宽高就可以访问，比如访问图片image.jpg，直接访问image_'width'x'height'，就可以得到你要的尺寸
爽过之后看下这个模块怎么用，知其然，知其所以然嘛
先来简单介绍一下image_filter的几个指令：
image_filter
image_filter_buffer
image_filter_interlace
image_filter_jpeg_quality
image_filter_sharpen
image_filter_transparency
image_filter_webp_quality
image_filter，最重要的指令，可选参数众多，分别是：
image_filter off; #开关
image_filter test; #测试指令，确保响应图片格式，否则415
image_filter size; #以json格式返回图片尺寸和类型
image_filter rotate 90 | 180 | 270; #逆时针选择指定度数，只有三个读书可选
image_filter resize width height; #按比例缩放
image_filter crop width height; #按比例裁剪
注意最后两个参数，一个是对图片进行缩放，另外一个是进行裁剪，这三个指令可以单独使用，也可以同时使用，同时使用的时候，执行的顺序是，先旋转，后缩放、裁剪
image_filter_buffer是设置读取图像的缓冲最大大小，默认值是1M，在使用image_filter的情况下，是415错误出现的最大罪魁祸首。当图片大于该指令指定的值时，会直接返回415错误码
image_filter_interlace指令有点意思，该指令启用之后，图像将隔行扫描，最终生成的图像是交错的，对于JPEG，最终图片是“渐进式JPEG”格式，通常情况下图片一般是线性加载，设置后则变成交替加载图片，什么是线性加载，什么是交替加载，通过两张图看一下：
以上是线性加载
以上是交替/渐进加载
你会觉得，这看着是不一样，但是又有什么特别的呢，下面给你好好上上课(我也是“偷”来的)
有个叫Ann Robson的大佬，对这两种加载方式做了测试，下面一张图就是他做的测试图
该图是在FireFox浏览器下呈现速度的对比图，当大图轮廓加载完成的时候，小图最后一个小猪仔还没有出世，而同样大小的线性加载的图，还没有开始加载！结论很明显，渐进式JPEG渲染速度更快，但是，凡事都有但是，这种方式需要更多的CPU消耗
image_filter_jpeg_quality指令是设置转换JPEG图像的质量，它的值范围是1~100，值越小，图片质量越低，相对数据传输量就越少，默认为75，最大建议95
image_filter_sharpen指令是设置锐化度，增加最终图像的清晰度，默认设置0，禁用此功能，根据情况设置，没啥说的
image_filter_transparency指令决定在转换GIF或PNG图片带有调色板定义的颜色时，透明是否会保留，这个视情况，自己看
image_filter_webp_quality指令是设置转换WebPage图像的质量，和jpeg质量一样，没得说，默认值80
理论说完了，该实际开搞了，先看下nginx怎么配：
是不是很简单，指令放location下，就搞定了，就这么简单！
当然，你要想玩得高级一点就没这么简单了，眼尖的话，可能发现了，我配置的resize是变量。
废话，不用变量，难道每次都改配置文件，重新加载吗？
看下这部分配置，首先通过location匹配图片的请求uri，这里有一个判断，是因为加了一个缓存，就是之前处理过的图片，存在缓存目录中，下次请求的时候不需要再做处理，节省CPU资源啊
如果在缓存目录里没有找到资源，资源，则重组uri，反向代理到image_filter的server，处理之后就会将处理的文件存储到缓存目录，这时就可以正常访问到处理过后的图片了
我这里的配置不能完全适用，需要根据uri自行写正则匹配，这里推荐一个正则在线测试的工具：https://regex101.com/，正则写不对，也会出现415的错误(踩坑之人血的教训)
现在你可以随意处理图片了
nginx的image_filter虽然无法像GraphicsMagick一样，有强大的图片处理功能，但是，操作简单，方便，灵活，能够实现实时裁剪，但是目前支持的图片类型只有JPEG、GIF、PNG、WebP，要注意的一点是CPU和内存消耗，访问量打的时候服务器压力会有一些，解决方法就是像我上面一样，缓存下来
另外一个要强力推荐的一个第三方module，"echo"，测试排错的绝佳工具，有什么问题，echo出来看！！！
持续更新，欢迎扫码关注，敬请期待！
温馨提示
如果你喜欢本文，请分享到朋友圈，想要获得更多信息，请关注我。